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ABSTRACT 



A system and method for conducting commerce over a 
distributed network manage merchant and product informa- 
tion in an electronic shopping basket, payment source infor- 
mation in an electronic wallet, and snipping address infor- 
mation in an electronic address book, all of such information 
being stored on a consumer computer. A commerce client 
running on the consumer computer is configured as a MIME 
handler and extends the functionality of a standard Web 
browser to support computer-based shopping. A merchant 
site Web server provides HTML-coded Web documents 
which describe merchant products and which host computer- 
based shopping options. The HTML-coded Web documents 
contain function-calling information by which consumer- 
selected options invoke shopping-related functions on either 
the merchant (server) computer or the consumer (client) 
computer. A consumer selects the options from within the 
Web browser to initiate shopping-related operations such as: 
retrieve product information from merchants on the World 
Wide Web, selectively store product information locally on 
the consumer computer, locally compare product informa- 
tion from different merchants, locally store payment source 
and shipping address information and selectively forward 
such information to merchant sites, order products from 
Web-based merchants, track the status of purchase orders, 
and receive instructional information on application usage. 

25 Claims, 12 Drawing Sheets 
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SYSTEM AND METHOD FOR CONDUCTING period of time (typically a few days), the consumer is under 

COMMERCE OVER A DISTRIBUTED a constraint to make use of the stored product infor- 

NETWORK mation. Moreover, many hundreds or thousands of requests 

by consumers to store product information on a merchant's 

PRIORITY 5 s * le ma y degrade the merchant site's response time, and 

create other problems related to the heavy storage burden. 

This application claims priority from the provisional Also, because existing computer-based shopping systems 

patent application No. 60/020,891 mailed Jun. 28, 1996, typically host most or all transaction options on the server 

titled, "SYSTEM AND METHOD FOR CONDUCTING side, the shopping experience often differs from merchant 

COMMERCE OVER A DISTRIBUTED NETWORK." 3Q site to merchant site. Specifically, as the consumer moves 

from one merchant site to the next, the options presented to 

BACKGROUND OF THE INVENTION tne consumer and the steps required to navigate and effec- 

1. Field of the Invention live!v ^ those °P tioDS often differ significantly. Thus, to 
' . . .. , browse product information and purchase products and/or 

This invention relates to distributed computer networks o£fered b mm , e merchams ^ coasamB ofteD 

such as the Internet. More pamcularly this invention relates « ^ tQ ^ ^ ^ n$ offefed eacQ merchanl 

to client-server software components for allowing consum- ^ 

ers to purchase goods and services from merchants over a .' , t , , , 

distributed network. Another problem with existing computer-based shopping 

systems is that they often require user entry of purchase 

2. Description of the Related Art ^ information and shipping information upon every purchase, 
Electronic shopping systems currently exist which allow or at least require consumers to identify themselves during 

users to remotely purchase goods and services from a variety each shopping session. These restrictions are time 

of different on-line merchants over a distributed computer consuming, tedious, and bothersome. Further, repeated entry 

network such as the Internet. With systems of this type, the 0 f payment information or shipping information increases 

on-line merchants typically publish on-line catalogs which 2$ the likelihood that a consumer will mistakenly enter incor- 

can be viewed interactively by the end users of the network re ct information. 

using a personal computer. These catalogs include pictures, -t^ prese nt invention addresses these and other problems 

textual descriptions, and pricing information with respect to w i ln existing electronic shopping systems. In accordance 

the products and/or services of the respective merchants, and with the invention, an electronic shopping system is pro- 

typically include on-line forms for allowing users to return 30 v ided which makes use of the existing client and server 

purchase orders to the merchants over the network. In World software components and protocols of the World Wide Web, 

Wide Web ("Web") based implementations, the on-line and which adds various client-side functionality for allowing 

catalogs are in the form of hypertext documents which are users to storej v j eWj anc j p roC ess product information 

hosted by the Web sites of the respective merchants, and the (gathered from merchant Web sites), payment information, 

catalogs are accessed using a standard Web browser appli- 35 and shipping information on the user computer. The system 

cation which runs on the user computer. (A Web site is an includes a specialized client application (referred to as the 

Internet-connected computer or computer system which "commerce client") which runs on the consumer computer 

runs server software for serving information using the in conjunction with a standard Web browser. The commerce 

standard protocols of the World Wide Web.) In other cuent communicates with a specialized commerce server 

implementations, the on-line catalogs may, for example, be 4Q (which runs on the merchant Web site in conjunction with a 

hosted by a centralized computer of an on-line services W eb server) using a bi-directional function calling protocol, 

network, such as MSN™, or by an Internet site which is Hypertext (HTML) catalog pages served by the merchant 

accessed using a proprietary client application (such as the Web site> as well ^ interface" hypertext documents 

client application of eShop Inc.). stored 0Q tne user computer, include embedded function 

45 calls which can be selectively invoked by the consumer 
while viewing the hypertext pages with the Web browser. 
Some computer-based shopping systems currently exist Using these embedded function calls, the user can perform 
which allow the user to selectively store product information actions such as: request pricing or inventory information on 
(and various other types of "shopping-state" information) a particular product from the merchant Web site; selectively 
for subsequent recall and use. This allows the user to rapidly 50 store product information within a client -side shopping 
bring up the information viewed during previous visits to the basket; view the contents of the shopping basket; and 
merchant site, and to essentially continue the shopping transmit encrypted shipping and/or payment information 
session where the user left off. Unfortunately, these systems (stored on the consumer computer) to the merchant Web site, 
generally store the product information on the server side In accordance with one aspect of the invention, there is 
only (e.g., on the merchant Web site), and do not include the 55 thus provided a method for gathering and comparing product 
necessary client and server software components for allow- information over a distributed network. The method com- 
ing the user to selectively store the product information on prises the steps of (a) sending a first hypertext document 
the consumer computer. This deficiency in the software over the distributed network to a user computer, the first 
architectures of existing computer-based shopping systems hypertext document comprising a description of (i) a first 
imposes several limitations on consumers. First, it makes it 60 product, (ii) a selectable product gathering option, and (iii) 
difficult for the consumer to gather product information from function-calling information associated with the product 
multiple merchants into a common, local storage area. This, gathering option; (b) displaying the first hypertext document 
in turn, makes comparison shopping very difficult: the to a user via the user computer and monitoring user input for 
consumer generally cannot, without considerable selection of the product gathering option; and (c) responding 
inconvenience, compare like products (or services) from 65 to selection of the product gathering option by calling an 
different on-line merchants. Second, because the informa- executable function specified by the function-calling 
tion is typically retained by the merchant site for a limited information, the function storing the description of the first 
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product to a data storage area accessible to the user com- FIG. 9 illustrates steps performed in viewing details about 

puter. Another embodiment of this aspect preferably com- a product from the electronic shopping basket; 

prises the further steps: (d) sending a second hypertext FIG. 10 illustrates the steps performed in viewing and 

document over the distributed network to the user computer, manipulating payment source data in the wallet object on the 

the second hypertext document comprising (i) a description 5 consumer computer; 

of a second product, (ii) a selectable product gathering FIG. 11 illustrates the steps performed in viewing and 

option, and (iii) function-calling information associated with manipulating shipping address data in the address book 

the product gathering option; (e) displaying the second on me consumer computer; and 

hypertext document to the user via the user computer and FIG. 12 illustrates the steps performed in purchasing 

monitoring user input for selection of the product gathering ao ducts ff0m mercham Web shes of tne tem 

option; (f) responding to selection of the product gathering Qver a distri5uled netW ork. 

option by calling a second executable function represented 

in the function^alling information, the function storing the DETAILED DESCRIPTION OF THE 
description of the second product to the data storage area; (g) PREFERRED EMBODIMENT 
displaying a product comparison option to the user via the is The present invention concerns electronic shopping and 
user computer and monitoring user input for selection of the provides the ability to use a personal computer to compare 
product comparison option; and (h) responding to selection an d purchase products offered for sale via a distributed 
of the product comparison option by retrieving from the network. The invention is embodied within a computer- 
local storage area the description of the first product and the based shopping system which utilizes the existing protocols 
description of the second product, and by formatting the 20 a nd components of the World Wide Web. The computer- 
descriptions and displaying the descriptions to the user via Dasec i shopping system is described in detail herein, 
the user computer. j n me preferred embodiment, the system includes a "com- 
Another aspect of the present invention is a method for merce client" process which runs on a consumer's computer 
using a Web browser to manage local data. The local data is in conjunction with a standard Web browser. The commerce 
stored on a computer storage medium accessible to the user 25 client communicates over the Internet with a "commerce 
computer. The method comprises the steps of: (a) receiving server*' (using a bi-directional function calling protocol) 
with the Web browser an HTML document (HyperText executing on a merchant Web site. In a preferred 
Markup Language) comprising a user-selectable view option embodiment, the commerce client includes functionality 
and function-calling information associated with the view similar to that of a shopping basket, a wallet, and an address 
option; (b) displaying the HTML document to a user via the 30 book, and the commerce server includes functionality for 
user computer, the display including the view option; (c) providing a variety of commerce-related services (such as 
monitoring user input for selection of the view option; and accessing or returning product information, calculating 
(d) responding to selection of the view option by calling a taxes, processing orders, etc.). 

function represented in the function-calling information, the The commerce client and commerce server operate 

function accessing and formatting the local data and dis- 35 together to allow a consumer to gather product information 

playing the local data to the user. fr 0m any number of merchants while the consumer's com- 

~™™,™™ T ™ ™^ ™ t „ 7TW _ puter is connected to the Internet. The commerce client also 

BRIEF DESCRIPTION OF THE DRAWINGS £ ermils the consumer lQ perform ^parison SDoppmg by 

These and other features of the invention are described reviewing product information gathered from various mer- 

below with reference to the drawings of a preferred embodi- chants. This product comparison can be performed by the 

ment of a computer-based shopping system, which is consumer at any time (e.g., while off-line) and over any 

intended to illustrate and not to limit the invention, and in length of time, regardless of whether the consumer's com- 

which: P utcr is connected to the Internet. 

FIG. 1 illustrates a consumer computer communicating 45 A user unfamiliar with the operation of a computer-based 

with two merchant Web sites of the system in accordance shopping system which embodies the present invention can 

with the present invention; access instructional information (or application help) by 

t*- - ... - , - r . selecting a help option. The instructional information is 

FIG. 2 illustrates a preferred protocol for transferring , ° r r TT ™, r j j i. j * i_* i. 

„ . r , r Li & stored on one or more HTML-coded Web documents which 

function call requests and responses between the consumer * > a 

* , . f , t . are retrieved and displayed according to the user s needs, 

computer and a merchant Web site of the system using the 50 . j . ■ . . . . 

HTTP message stream between a standard Web browser and computer-based shopping system embodying the 

a Web server present invention permits a user to purchase products from 

. . * r r r an on-line merchant. The consumer uses the commerce 

HG. 3 illustrates a preferred software architecture for the diem tQ authorize payrnent , select a payment source, select 

merchant Web sites of the system; a shipping addre ss (none of which require network 

FIG. 4 illustrates a preferred software architecture for the connection) and also to place an order to the merchant for 

consumer computers of the system; the selected product. A network connection is established for 

FIG. 5 illustrates data structures accessed and manipu- the commerce client to communicate the order to the com- 

lated by shopping basket, wallet, and address book objects merce server. The payment and shipping information is 

on the consumer computer; 6Q protected from third party discovery using encryption tech- 

FIG. 6 illustrates the steps performed in adding informa- nology. 

tion (served by a merchant Web site) about a product to the The following sections and subsections describe the 

shopping basket object; invention in more detail: 

FIG. 7 illustrates the steps performed in viewing product A. Glossary of Terms and Acronyms 

information stored within the shopping basket; B. Example Computer-Based Shopping Session 

FIG. 8 illustrates the steps performed in deleting a product C. Communication Between Commerce Client and Com- 

from the shopping basket; merce Server 
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D. Software Architecture of Merchant Web Site Port or Port Number. 

E. Software Architecture of Consumer Computer (Also referred to as "socket number.") In the context of 

the Internet, a numerical identifier (normally provided in 

A. Glossary of Terms and Acronyms conjunction with an IP address) which is used by TCP/IP to 

m „ „ , . , , 5 direct incoming data to a particular application. Certain 

The following terms and acronyms are used throughout pQrts faave beeQ rescrvcd by the Internet Assigned Number 

the detailed description: Authority (IANA) for certain applications. For example, 

Internet. port 80 is reserved for HTTP, and is used on Web sites to 

A collection of interconnected (public and/or private) direct incoming traffic to a Web server. (See "URL" below.) 

networks that are linked together by a set of standard 10 URL (Uniform Resource Locator), 

protocols (such as TCP/IP and HTTP) to form a global, a unique address which fully specifies the location of a 

distributed network. (While this term is intended to refer to fii e or ol her resource on the Internet. The general format of 

what is now commonly known as the Internet, it is also a URL is protocol://machine address: port/path/filename, 

intended to encompass variations which may be made in the Th e port specification is optional, and if none is entered by 

future, including changes and additions to existing standard 35 the user, the browser defaults to the standard port for 

protocols.) whatever service is specified as the protocol For example, 

World Wide Web ("Web"). if HTTP is specified as the protocol, the browser will use the 

Used herein to refer generally to both (i) a distributed HTTP default port of 80. 

collection of interlinked, user-viewable hypertext docu- HTTP (Hypertext Transport Protocol), 

menis (commonly referred to as "Web documents" or "Web 20 jh e standard World Wide Web client-server protocol used 

pages") that are accessible via the Internet, and (ii) the client for the exchange of information (such as HTML documents, 

and server software components which provide user access and client requests for such documents) between a browser 

to such documents using standardized Internet protocols. and a Web server. HTTP includes a number of different types 

Currently, the primary standard protocol for allowing appli- of messages which can be sent from the client to the server 

cations to locate and acquire Web documents is HTTP 25 to request different types of server actions. For example, a 

(discussed below), and the Web pages are encoded using "GET" message, which has the format GET <URL>, causes 

HTML (also discussed below). However, the terms "Web" the server to return the document or file located at the 

and "World Wide Web" are intended to encompass future specified URL. 

markup languages and transport protocols which may be HTTP POST. 

used in place of (or in addition to) HTML and HTTP. 30 A type of HTTp message whicn ^ used to req uest that the 

Client-Server. Web server accept information from the Web client. This 

A model of interaction in a distributed system in which a information may, for example, be in the form of a message 

program at one site sends a request to a program at another to be posted to a newsgroup, or a database submission which 

site and waits for a response. The requesting program is is executed by a CGI script. (See "CGI" below.) 

called the "client," and the program which responds to the 35 MIME (Multipurpose Internet Multimedia Extensions) 

request is called the "server." In the context of the World Type. 

Wide Web, the client is a "Web browser" (or simply A file extension or attachment which specifies the type or 

"browser") which runs on a computer of a user; the program f ormat 0 f the file (e.g., HTML, text, graphics, audio, etc.). 

which responds to browser requests by serving Web pages is MIME typing allows the Web browser to determine how.to 

commonly referred to as a "Web server." process a file that is received from a Web server. For 

TCP/IP (Transmission Control Protocol/Internet example, a file of MIME type HTML (extension ".htm" or 

Protocol). ".html") will be displayed by the browser, while a file of 

A standard Internet protocol (or set of protocols) which MIME type X-WAV (extension ".wav") will typically be 

specifies how two computers exchange data over the Inter- 45 passed to an audio player which can handle the Microsoft 

net. TCP/IP handles issues such as packet ization, packet WAV format. Standard Web browsers come pre-configured 

addressing, handshaking and error correction. For more to handle popular MIME types. In addition, standard Web 

information on TCP/IP, see Volumes I, II and III of Comer browsers can easily be configured by the user to handle new 

and Stevens, Internetworking with TCP/IP, Prentice Hall, MIME types; this typically involves specifying the file 

Inc., ISBNs 0-13-468505-9 (vol. I), 0-13-125527-4 (vol. II), 50 extension of each new MIME type, and specifying the path 

and 0-13-474222-2 (vol. III). and filename of the application (referred to as a "MIME 

HTML (HyperText Markup Language). handler") to which files of such type should be passed. 

A standard coding convention and set of codes for attach- Internet Firewall, 
ing presentation and linking attributes to informational con- A security system placed between the Internet and an 
tent within documents. (HTML 2.0 is currently the primary 55 organization's network (such as a LAN) to provide a barrier 
standard used for generating Web documents.) During a against security attacks. Internet firewalls typically operate 
document authoring stage, the HTML codes (referred to as by monitoring incoming and/or outgoing traffic to/from the 
"tags") are embedded within the informational content of the organization's network, and by allowing only certain types 
document. When the Web document (or "HTML ot messages to pass. For example, a firewall may be con- 
document") is subsequently transferred from a Web server to 60 figured to allow the passage of all TCP/IP traffic addressed 
a browser, the codes are interpreted by the browser and used t0 P orl 80 > and 10 olock a11 otner traffic. For more informa- 
to parse and display the document. In addition to specifying tion of Internet Firewalls, see Chapman and Zwicky, Build- 
how the Web browser is to display the document, HTML in S Internet Firewalls, O'Reilly publishing, 1995 (ISBN 
tags can be used to create links to other Web documents 1-56592-124-0). 
(commonly referred to as "hyperlinks"). For more informa- 65 CGI (Common Gateway Interface), 
tion on HTML, see Ian S. Graham, The HTML Source Book, A standard interface which specifies how a Web server (or 
John Wiley and Sons, Inc., 1995 (ISBN 0471-11894-4). possibly another information server) launches and interacts 
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with external programs (such as a database search engine) in commerce client 122 writes encrypted payment source data 

response to requests from clients. With CGI, the Web server to the data storage area 112. After entering the payment 

can serve information which is stored in a format that is not source information once and verifying its accuracy, the 

readable by the client, and present such information in the information persists on the consumer computer 102 without 

form of a client-readable Web page. A CGI program (called 5 requiring re-entry by the consumer. The consumer desig- 

a "CGI script") may be invoked, for example, when a Web nates one of the payment sources stored as the preferred 

user fills out an on-screen form which specifies a database payment source. 

query. One disadvantage of CGI is that it generally requires The consumer also stores shipping address information 

the launching of a separate process for each client request 142 to the storage area 112 via the consumer computer 102. 

received. For more information on CGI, see Ian S. Graham, 10 Shipping address information indicates preferred destina- 

The HTML Source Book, John Wiley and Sons, Inc., 1995 tions for delivery of products and includes, for example, a 

(ISBN 0471-11894-4), pp. 231-278. personal residence address, a P.O. Box, or a business 

ISAPI (Internet Server Application Program Interface). address. Again, the commerce client 122 writes shipping 

Microsoft's interface for allowing a Web server (or other address information 142 entered by the consumer to the 

information server) to launch and interact with external 15 storage area 112. After the preferred shipping destinations 

programs in response to requests from clients. ISAPI pro- are entered, they need not be entered a second time. As done 

grams are in the form of dynamic link libraries (DLLs) with the payment source data, the consumer designates one 

which run in the same process space as the Web server. Thus, shipping address as the preferred shipping address. 

ISAPI performs a similar function to that of CGI, but A consumer uses the consumer computer 102 to shop for 

without requiring the launching of a separate process. Docu- 20 products such as, for example, an audio compact disc, a 

mentation on ISAPI is available from Microsoft Corporation downloadable software program, a rare con, or a 

as part of the Microsoft Internet Information Server Soft- refrigerator, offered by merchants via the World Wide Web 

ware Development kit. 108. Using the example of shopping for a refrigerator, the 

consumer uses the consumer computer 102 to establish a 

B. Example Computcr-Based Shopping Session 25 COQDectioo t0 the internet and uses a Web browser to 

This section provides an illustration of a hypothetical navigate World Wide Web 108 sites. Connecting to the 

computer-based shopping session wherein features of the Internet and browsing the WWW is well known and the 

present invention are used. FIG. 1 illustrates a consumer steps involved will not be further described, 

computer 102, a first merchant site ("merchant site A") 104, 3Q The consumer uses the Web browser 120 to access a 

and a second merchant site ("merchant site B") 106, each merchant site A 104 on the WWW. The Web server 128 of 

connected to the Internet and utilizing the World Wide Web merchant site A 104 responds to the access initiated by the 

("WWW") 108. Merchant site A 104 and merchant site B consumer computer 102 by retrieving a first HTML docu- 

106 host shopping-oriented transactions to advertise and sell ment (i.e., a collection of data encoded in compliance with 

products over the Internet. The consumer computer 102 and 35 the Hyper-Text Markup Language) from the set of HTML 

merchant Web sites 104, 106 run client and server software documents 144, and by then transmitting the first HTML 

applications which allow a consumer to browse product document to the Web browser 120 of the consumer computer 

information advertised over the WWW, gather information 102. 

about products and merchants, selectively store the product The Web browser 120 interprets the HTML document and 

and merchant information in a client side database, compare 4Q creates on the monitor 114 a page -oriented representation of 

product information from different merchants, and purchase the document. The consumer views the document on the 

products sold over the Internet. monitor 114. The document may, for example, present 

The consumer computer 102 comprises a processing unit textual information to the consumer describing merchant site 

110, a data storage area 112, as well as a monitor 114, A 104 such as the nature of products offered and the forms 

keyboard 116, and a mouse 118. A standard Web browser 45 of payment accepted in filling orders for the products. The 

120 (such as, for example, Microsoft Internet Explorer 2.0 consumer may, for example, discover that merchant site A 

or Netscape Navigator 2.0) and a specialized commerce offers refrigerators for sale and accepts VISA for payment, 

client process 122 execute on the processing unit 110. Generally, consumer-selectable options ("hypertext 

Merchant site A 104 comprises a processing unit 124 and links") are also presented within the HTML document 

a data storage area 126 which stores HTML documents 144 50 which, if selected by a consumer using the mouse 118 or the 

and merchant databases 146. A standard Web server 128 keyboard 116, cause the consumer computer 102 to transmit 

(such as Microsoft Internet Information Server 1.0) and a requests to the Web server 128 to retrieve and transmit 

specialized commerce server 130 execute on the processing additional HTML documents providing related or more 

unit 124. Likewise, merchant site B comprises a processing detailed information. The consumer navigates additional 

unit 132 and a data storage area 134 which stores HTML 55 hypertext links and browses additional HTML documents 

documents 137 and merchant databases 139. A standard Web summarizing features of refrigerators sold by merchant site 

browser 136 executes on the processing unit 132, as does a A. 

specialized commerce server 138. The consumer decides that one of the refrigerators offered 
A consumer using the consumer computer 102 stores by merchant site A is well-suited to the consumer's needs. A 
payment source information 140 such as a credit card 60 number of attributes are presented to the consumer, each 
number, expiration date, and issuing bank to the storage area attribute capable of being set to one of a number of values. 
112. The consumer supplies a password in association with Thus, for example, the user sets a color attribute to "Egg 
the payment source information. The password is used not Shell White," sets an indoor water spout attribute to "No," 
only to prevent future unauthorized accesses, but also to and an automatic ice-maker attribute to "Yes." The con- 
encrypt the payment source information. The payment 65 sumer then selects an option labeled, for example, "Add 
source information represents preferred sources of cash Item to Shopping Basket." The Web browser 120 directs a 
and/or credit for purchasing products and/or services. The corresponding message to the commerce client 122 causing 
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information about the selected merchant A refrigerator, shipping addresses can be recorded. The standard Web 

including the attributes selected, to be stored in a gathered browser 120, so extended, offers consumers an extremely 

products database 148. (The protocols and software com- convenient and consistent method of shopping for products 

ponents which enable this type of operation to be performed over the World Wide Web. This section describes a method 

are described in the following sections.) Such information 5 for a Web browser to call functions on both its own local 

includes, for example, a picture of the refrigerator, cubic foot computer and also on a computer executing a Web server, 

capacity, temperature range, energy usage, manufacturer's Additionally, a method is described for allowing a Web 

warranty, price, the attributes set by the consumer, the URL j*™ 10 cal1 MoDS 0Q a computer executing a Web 

of merchant site A, and also includes a preferred payment browse r. ... 

source and a preferred shipping address. The consumer then 10 HG ' 2 i"™ 8 communication between a consumer 

ends the shopping session with merchant site A either by com P uter 102 a ° d a merchant computer 202. A consumer 

accessing a different World Wide Web site or by directing the accesses a merchant "^"S. ° D " 7™ 

consumer computer 102 to terminate the network connection ««»™« cwnputer 1<B. IIk consumer computer 102 

to the Internet includes a standard Web browser 120, and the merchant 

m . , , „_ computer 202 includes a Web server 128. The Web browser 

Two days later, the consumer agarn having time to shop, « m ^ ^ Web m ux me Hrrp ^ (<) 

directs the consumer computer 102 to connect to merchant communicate ^ each other over lhe Internet . 

site B via the World Wide Web. Merchant site B also offers ™_ „. , , 4 

c . .j. i at * * * *l t jjrj^Mj . The Web server 128 running on the merchant computer 

refrigerators for sale. After navigating through HTML docu- . . AA ? c „™ JfI , , , , 

f j .1. * *. e .i_ c * . u l 202 accesses a local store 144 of HrML documents (also 

ments describing the features of the refrigerators sold by , - . , t( ... , . , „ u \„ . 

. . c . . .u ™ commonly referred to as Web documents or Web 

merchant site B, the consumer selects a refrigerator, sets the 20 . .... , ( . 

f . . ., t , . , , 4U «ajji. pages ). When the Web browser 120 on the consumer 

refrigerator attributes as desired, and invokes the Add Item i- *» / itt^* t j . *u wj u 

, ef • tl • ... computer 102 requests an HTML document, the Web server 

to Shopping Basket option. The commands to accomplish 1^0 ♦ ■ tU Im „ , , , ' - t , tU 

... rr , ° ,, r -j.jji.-f.- 128 retrieves the HTML document and transmits it to the 

this are the same as those required to add the information „, , , -- n . , 1A1 , v 

, . t . . * -* a c 4 , lL L . , t Web browser 120 on the consumer computer 102 where it is 

about the merchant site A refrigerator to the shopping basket. • j . . ^ j • n • i j 

™ i j . . , viewed by the consumer. These documents typically include 

I ne commerce client 122 responds to the invoked option by 25 . r . . . . « ■ / 

... . f , . r u . u r • . / information about the merchant, as well as information 

adding information about the merchant site B refrigerator to . , . , t . , . . . , r , .. 

(L i . i j * i_ . t*i_ lL about the products sold by the merchant (including pictures 

the gathered products database 148. The consumer then . , Y . - , ' , , ; . . &r 

• . .u u • -.u u * •* n iaz: and descriptions of products and product prices), 

terminates the shopping session with merchant site B 106. ^ r . , r ...... 

_ . , , , To provide more sophisticated shopping transactions 
TTn-ee weeks later, the i consumer uses the consumer com- between consumers and mer chants, software dedicated to 
puter 102 to compare the information about the merchant idi co^mer-oriented shopping functions (the corn- 
site A refrigerator and the merchant site B refrigerator. The mcrce clicm m) cxecutes Qn a aad 
consumer does not need to connect to the World Wide Web softwafe dedicated lQ ovidin mer chant-oriented functions 
to compare the two refrigerators The consumer invokes an (the commerce 130) executes on a merchant com ter 
option entitled, for example "View Items m Shopping 2Q2 Qne objectiye Qf ^ { invention ^ tQ Qvide 
Basket Hie commerce client 122 extracts the information ^ a mmmm client m on the ^ 
about the two refrigerators from the gathered products CQm ter m which communicates directly with the Web 
information 148, and formats the "formation such that the bfOWSer m and a commerce server 130 mnai on the 
consumer can view it o 0 ithe monitor -U4. After weighing the mefcham CQ 2Q2 which directly with 
features, warranties, and prices of the two refrigerators, the tbe ^y eb 

consumer decides to purchase the merchant site A refrigera- 40 ™ ' 4 . . 

r & The commerce chent 122 and the commerce server 130 

utilize the Internet-based communication between the Web 

The consumer then authorizes access to the payment browser 120 and the Web server 128 to communicate with 

source and address information stored on the consumer each otner ^ extensible Web function-calling protocol 

computer by entering a password known only to the con- 45 ("wpcp.) perrails the commerce client 122 and the com- 

sumer. After the consumer enters the password, the com- merce 130 t0 pass funclions ca i Ls t0 each other by 

merce client 122 accesses the payment source information embedding the function calls in data exchanged via the 

140, decrypts the information, combines it with information i nter net by the Web browser 120 and the Web server 128. As 

about the merchant A refrigerator to assemble a goods and illustrated in FIG. 2, the Web function-calling protocol 

services order ("GSO"). The GSO is then encrypted and 5Q effectively "tunnels" function-calling information (requests 

included as part of an HTTP POST message which is sent to and reS ponses) through an HTTP message stream (shown in 

the URL of merchant A. Merchant A receives the message, dashed bctween the standard Web browser 120 and the 

decrypts it, processes the order, and ships the product to the We5 server 128 0ae significant bene fit of the use of HTTP 

consumer's specified shipping address. ^ that it allows lhe consumer computer 102 to communicate 

A few years after purchasing the refrigerator, the con- 55 with merchant Web sites from behind Internet firewalls 214 

sumer examines a product purchasing history to determine, which permit passage of HTTP traffic, 

for example, whether the refrigerator is still under warranty. The Web server 128 serves HTML documents which 

The electronic shopping basket retains a complete, brows- include embedded function calling information. This func- 

able history of all products purchased. t i on calling information is embedded in a hidden form using 

~ _ _ ,60 standard HTML tags, and is provided in a predefined format 

C. Communication Between Commerce Client and / - a j _ c .u \\rrr*r>\ »u . • • j u l . L 

^ _ (specified as part of the WFCP) that is recognized by both 

Commerce Server t . 4 1 « . 1in 

the commerce client 122 and the commerce server 130. 

The present invention extends the functionality of the Generally, the embedded function calling information cor- 

standard Web browser 120 by adding shopping- related responds to consumer-selectable options (e.g., hyperlinks or 

features, namely, a shopping basket in which product infor- 65 buttons) within HTML documents to allow a consumer to 

malion can be gathered, a wallet in which sources of initiate client-to-server function calls across the Internet by 

payment can be stored, and an address book in which selecting (with mouse or keyboard) transaction options. 
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FIG. 2 illustrates an HTML document 206 being dis- 
played by the Web browser 120. The HTML document 206 
includes a consumer-selectable button 208 associated with a 
textual description (such as "buy," "update shopping 
basket," "retrieve price information," or "retrieve account 
information") of a corresponding action to be performed. 
When the consumer clicks on this button, corresponding 
function-calling information is passed across the Internet as 
a standard HTTP POST message from the consumer com- 
puter 102 to the merchant computer 202. 

The function calling information for making a corre- 
sponding function call typically includes the name of an 
object, an object interface, a method, and an argument list. 
If the button 208 activates a "Calculate Tax" option, the 
corresponding function -calling information associated with 
the button may, for example, include the text: 

OBJECT-MSTaxEngine.l 

INTERFACE-ITaxCalculation 

METl IOD=CalculateTaxDue 

ARGS=arglist 

This function-calling information is provided in the HTML 
document along with a target URL (of the merchant Web site 
104, 106) such that an HTTP POST message containing the 
information will be sent to the URL if the consumer clicks 
on the button 208. One example of an HTML-coded form of 
the HTTP POST message is: 



10 



15 



20 



25 



the context of electronic shopping, the response message 
may include, for example, price or inventory information for 
a particular product, or the result of a tax calculation 
requested by the consumer.) The response may include a 
function call or other information directed specifically to the 
commerce client 122. The Web browser 120 receives all data 
transmitted from the merchant computer 202 to the con- 
sumer computer 102. However, some of the data received by 
the Web browser 120 is further routed to the commerce 
client 122. 

The Web server 128 transmits data to the consumer 
computer 102 by first packaging the data as a MIME 
message and then sending the MIME message across the 
Internet from the Web server 128 to the Web browser 120. 
If the response message is in the form of an HTML response 
to be displayed by the Web browser 120, the MIME type of 
the message will be HTML. If, on the other hand, the 
response message is directed to the commerce client 122 
(such as when the response includes non-HTML product 
information), the response message will be tagged with a 
MIME type which corresponds to the commerce client 122, 
causing the Web browser 120 to forward the message to the 
commerce client 122. 

In the preferred embodiment, the MIME type associated 
with the commerce client is "x-ishopper." The message 
generated on the server side may include information to call 
a function on the consumer computer 102, in which case the 



<HTML> 

<!---WFCP FORMATTED CALI^--> 
<FORM ACTION-http://www.merchant.com;mig.dn 
METHOD-" POST' 

ENCTYPE«"app licatio n/x- www-fo nn-urlencoded' '> 
<[NPUT type-hidden name=0 EJECT value-MSTaxEngine.l> 
<tNPUT type-hidden name= INTERFACE value«ITaxCalculation> 
<INPUT type-hidden name= METHOD value«=CalculateTaxDue> 
<INPUT type-hidden name-ARGS value=arglist> 
<[NPUT type-submit value-'Calculatc Sales Tax"> 
</FORM> 
</HTML> 



Although the target URL in this example corresponds to the 
Web site that is the source of the HTML document, the target 
URL could be that of a different Web site. 

Thus, when the consumer clicks on the button 208, the 
Web browser 120 generates an HTTP POST message coded 
using HTML and sends the HTTP POST message to the 
URL of the merchant Web site 104, 106. This message 
includes function-calling information (object, interface, 
method and arguments) to invoke a method (i.e., a software 
callable procedure or function) of a method library 212 on 
the merchant computer. If multiple function calls were 
linked to the button 208, the HTTP POST message would 
include the function-calling information for each such func- 
tion call. 

Upon receipt of the HTTP POST message, the Web server 
128 parses the message, invokes the commerce server 130 
(if not already executing) and passes the function-calling 
information to the commerce server 130. The commerce 
server 130 then invokes the specified object, and passes the 
arguments to the specified method using the specified inter- 
face; the commerce server 130 thereby makes the function 
call on behalf of the commerce client 122. Depending upon 
the method called, the function call may, for example, 
involve a query of and/or an update to a merchant database. 

This function call will typically produce a response which 
must be communicated to the consumer computer 102. (In 



MIME message will include function-calling information. 
This server-to-client function-calling information specifies 

45 the object, method, interface, and arguments of the client- 
side function call and is specified within the MIME message 
using the same format (illustrated above) as used for client- 
to-server function calls. 
Upon receiving a MIME message of type "x-ishopper," 

50 the Web browser 120 strips off the MIME headers and passes 
the message to the commerce client 122. As described 
further below, the commerce client 122 acts as a MIME 
handler for messages of type "x-ishopper." The commerce 
client 122 then invokes the method indicated in the MIME 

55 message on the consumer computer 102 in the same manner 
performed by the commerce server 130 on the merchant 
computer 202. 

Thus, using HTTP POST messages and MIME messages, 
function calls are placed on the merchant computer 202 by 

60 the consumer computer 102 and function calls are placed on 
the consumer computer 102 by the merchant computer 202. 
Advantageously, WFCP is not tied to any specific function 
or set of functions. Thus, new client-side and server-side 
functions can be added (and embedded within HTML 

65 documents) without modification to the existing function- 
calling components. The WFCP protocol is described in 
further detail in a copending U.S. patent application Ser. No. 
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08/670,882, entitled SYSTEM AND METHOD FOR MAK- 
ING FUNCTION CALLS OVER A DISTRIBUTED 
NETWORK, filed Jun. 28, 1996, which is hereby incorpo- 
rated by reference, in its entirety. 

A further advantage, however, is gained in providing the 5 
Web browser 120 with a method to invoke local functions on 
the consumer computer 102. Using the same HTTP POST 
message format, the Web browser 120 invokes local func- 
tions by specifying a URL address that resolves to a local 
port. Rather than addressing an HTTP POST message to a 10 
remote site on the Web by using a URL similar to "http:// 
www.sporting_goods.com", the Web browser 120 directs 
the HTTP POST to the local consumer computer 102 by 
using the URL "127.0.0.1:100" (note that ":100" specifies 
local port 100). This method of directing an HTTP POST is 
message to the local computer is facilitated by the local host 
service of the TCP/IP protocol stack. The URL "127.0.0.1" 
is a local loop-back address recognized by the local host 
service as identifying the local machine as the recipient of 
the message. 20 

A port listener process operates on the local machine 102 
monitoring a designated port such as, for example, port 100. 
The port listener receives the HTTP POST message, parses 
the content, and passes function-calling data directly to the 
commerce client 122. Thus, local functions are invoked by 25 
selected options coded in and hosted by a Web document 
wherein function-calling information is associated with the 
selected optioas. This method for making local function 
calls from a Web browser is described in further detail in a 
copending U.S. patent application Ser. No. 08/671,580, 30 
entitled SYSTEM AND METHOD FOR MAKING FUNC- 
TION CALLS FROM A WEB BROWSER TO A LOCAL 
APPLICATION, now U.S. Pat. No. 5,956,483 issued Sep. 
21, 1999, which is hereby incorporated by reference in its 
entirety. 35 

It will be appreciated by those skilled in the art that 
f specialized client and server processes provide substantial 
■ benefits in the context of computer-based shopping. For 
example, a merchant can conveniently store relatively static 
catalog information as HTML documents, while storing 40 
relatively dynamic product information (such as price and 
inventory) in a separate database (not shown in FIG. 2) 
which is accessed by the commerce server 130. This product 
information may advantageously be stored and served in a 
format which is recognized only by the specialized com- 45 
merce client 122 (as opposed to the standard Web browser 
120). Because the commerce client 122 runs in conjunction 
with the Web browser 120, the commerce client 122 can 
readily store both consumer-selected HTML (catalog) data 
from Web pages of merchants, and the associated non- 50 
HTML product information retrieved via client-to-server 
function calls. 

As noted above, because all information is passed via 
HTTP, the commerce client 122 and commerce server 130 
can advantageously communicate through Internet firewalls 55 
214 which are typically configured to permit the passage of 
TCP/IP messages addressed to port 80 and which, for 
security reasons, are configured to block communications 
addressed to other ports. 

Although FIG. 2 depicts a single Web server 128 inter- 60 
acting with a single commerce server 130, it will be recog- 
nized that other system configurations are possible. For 
example, multiple Web servers 128 could be provided 
(running on the same machine or on different machines) 
which interact with a single, shared commerce server 130; 65 
or, multiple commerce servers 130 could be provided which 
interact with a single Web server 128. 
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D. Software Architecture of Merchant Web Site 

FIG. 3 illustrates a preferred architecture of a merchant 
Web site 302 of the computer-based shopping system. As 
shown in FIG. 3, the merchant Web site 302 includes a 
merchant computer 202, a storage device 304 
(corresponding in function to the storage device 144 of FIG. 
2), and an Internet connection 306. Software operating on 
the merchant computer 202 includes a Web server 128, the 
commerce server 130, and a method library 308 
(corresponding to the method library 210 of FIG. 2). A 
collection of Web documents 310 is stored on the storage 
device 304 as are various merchant databases 312. 

The merchant Web site 302 may, for example, be a 
stand-alone site which independently serves information 
with respect to a single merchant, or may be in the form of 
(or a part of) a centralized or distributed electronic mall 
system which serves the information of many different 
merchants. The Web server 128 is preferably the Microsoft 
Internet Information Server version 1.0, although other 
conventional Web servers can be used. The commerce server 
130 is preferably in the form of an IS API (Internet Server 
Application Program Interface) DLL (dynamic link library) 
which runs within the same process space as the Web server 
128. The commerce server 130 has access to commerce 
server objects 314 located within the same process space as 
the commerce server 130 and the Web server 128. A CGI 
script, or a DLL which uses another server extension API 
(such as NSAPI from Netscape), could alternatively be used. 

The Web documents 310 stored on the merchant Web site 
302 are preferably coded using HTML. The Web documents 
310 contain HTML coding which, when received by a Web 
Browser 120, display various icons or buttons on the screen 
114 of the consumer computer 102 along with text or 
pictures comprising the content of the Web document. As 
described above, these icons or buttons comprise selectable 
options which correspond to shopping-related transactions. 
In the preferred embodiment, the Web documents 310 offer 
consumers options to add product information to an elec- 
tronic shopping basket, view products collected but not yet 
purchased, view products already purchased, enter payment 
information into an electronic wallet, place shipping 
addresses in an electronic address book, as well as order 
goods from Web-based merchants. These selectable options 
coded into the Web documents 310 have function-calling 
information associated with them (as described above) to 
invoke executable functions on the consumer computer 102 
or back on the Web server 128 when selected. Web docu- 
ments with embedded client-side function calls are also 
preferably stored on the hard disk of the consumer computer 
102 as part of the user interface of the commerce client 130, 
allowing the user to invoke client-side functions (such as 
viewing the shopping basket) while off-line. 

The method library 308 of the merchant Web site includes 
methods for performing client services such as retrieval of 
product information, calculation of sales taxes, and capture 
of orders. Some of these methods are listed and described in 
Table 1. 

TABLE 1 

Method Description 

Get Line [tern Retrieves product information given SKU (stock 
keeping unit) number or other product identifier. 

GetPrice Retrieves price information given SKU number or 

other product identifier. 
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Method 



Description 



CalculateSH Calculates shipping and handling costs given 
product/5 and shipping logistics (e.g., 
shipping address and method). 
CalculaleTaxDue Calculates shipping and handling costs given 
product/s and shipping logistics 
Captures order submitted by consumer, and processes 
in a manner specified by merchant. 



ProcessOrder 
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The commerce server 130 performs two primary tasks. 
First, when a request is received for product information (via 
function-calling information embedded within an HTTP 
POST message received by the Web server 128), the com- 
merce server retrieves various data items in connection with 
a product, such as SKU (stock keeping unit) number, prod- 
uct name, product description, logo, price, expiration date, 
tax, and shipping charges. This data is packaged as a MIME 
file of type "x-ishopper" and sent back to the consumer 
computer 102 via the Web browser 120, as described above. 
Second, the commerce server 130 captures and processes 
orders for products submitted by consumers. 

In accordance with the present invention, the merchant 
sites of the system prepare and serve HTML Web documents 
310 which present uniform transaction options, such as View 
Shopping Basket, Show Wallet, and Initiate Payment. 

Due to the wide variety of inventory management systems 
and legacy (long-existing and difficult to change) product 30 
information databases, as well as accounts receivable 
systems, the commerce server will often comprise custom 
interface software that will change from merchant to mer- 
chant. The present invention is primarily concerned with the 
consumer platform. 35 

E. Software Architecture of Consumer Computer 

FIG. 4 illustrates the software architecture of the con- 
sumer computer 102. The architecture comprises a conven- 
tional Web browser 120 (such as Microsoft's Internet 40 
Explorer 2.0, or Netscape Navigator 2.0), the commerce 
client 122, and a commerce client object library 402, and a 
storage area 112. The commerce client object library 402 
comprises a shopping basket object 404 having associated 
shopping basket methods 406, a wallet object 408 having 45 
associated wallet methods 410, and an address book object 
412 having associated address book methods 414. The 
storage area 112 comprises merchant information 416, prod- 
uct information 418, payment source data 140, and shipping 
address data 142, all of which has been selectively stored 50 
and/or manually entered by the user. 

The Web browser 120 is preferably configured such that 
the commerce client 122 is a MIME-handler application. 
Generally, a MIME-handler is a software application 
designed to provide specialized processing of specific types 55 
of files received over the Internet by a Web browser 120. The 
Web browser 120 of the present invention is configured to 
associate the MIME type "x-ishopper" with a certain file 
name extension such as "ish." When the Web browser 120 
receives a file of type "x-ishopper," the Web browser will 60 
cause the commerce client 122 application to begin execut- 
ing (if not already running). The Web browser 120 will then 
pass the received "x-ishopper" file to the commerce client 
122 for further processing. Extending the functionality of a 
Web browser by configuring the Web browser to associate 65 
specific file types with file name extensions and then asso- 
ciating specialized MIME-handler applications with file 



name extensions is well known and will not be further 
discussed herein. 

The commerce client 122 executes on the consumer 
computer 102 as a separate process from the Web browser 
120 and is a standard executable program. The commerce 
client 122 begins executing when launched by the Web 
browser 120 upon the Web browser's receipt of a file of 
MIME type "x-ishopper." Another way in which the com- 
merce client 122 begins executing is when a local port 
listener task receives a message from the Web browser 120 
which was directed at a local port. The port listener launches 
the commerce client 122 if it is not already executing. 

Still another way of launching the commerce client 122 is 
by running the commerce client program directly. As 
explained below in more detail, many functions ("local" 
functions) of the commerce client 122 do not require an 
Internet connection or transmission of data to or from a Web 
site. These local functions are available via user-interface 
HTML documents which reside on the consumer computer's 
hard disk. The commerce client 122 executes until the 
consumer selects an option causing the commerce client 122 
to stop executing. 

When the commerce client 122 starts running, it performs 
an initial task of loading structures in memory from data 
stored on the hard disk or other fixed storage media. The data 
represent merchant information, product information, pay- 
ment source information, and shipping addresses. The data 
are stored in such a way as to be easily read into memory 
while maintaining relationships (links) among the data. Such 
construction of interlinked in -memory structures from data 
stored on a hard disk is well known in the art. When the 
commerce client 122 shuts down or otherwise terminates 
normally, it writes the interlinked in-memory structures to 
hard disk storage in a manner that preserves all the relation- 
ships among the data. 

The data comprising the in-memory data structures are 
accessed and manipulated through objects. The shopping 
basket object 404 is associated with shopping basket meth- 
ods 406 which read, write, modify, and display information 
about merchants and/or products of interest to the consumer. 
The shopping basket methods 406 interact primarily with 
in-memory structures comprising product and merchant 
information. In accordance with the present invention, data 
for each product are preferably organized into groups as 
shown in Table 2. 



TABLE 2 


Product Data Field 


Description 


Logo 


Picture associated with product. 




Type: VOID* 


LogoSize 


Size of Picture associated with product. 




Type: DWORD 


Name 


Name of product. 




Type: Cstring 


Description 


Description of product. 




Type: Cstring 


Price 


Unit Price of product. 




Type: Currency 


Quantity 


Quantity of product to order. 




Type: Float 


Expiration Date 


Date on which offered price expires. 




Type: Cstring 


Tax 


Amount of tax computed for sate of product. 




Type: Currency 


ShippingCharge 


Cost to ship product as ordered. 




Type: Currency 



11/22/2003, EAST version: 1.4.1 



6,125,352 



17 



TABLE 2-continued 


Product Data Field 


Description 


OtherChargcs 


Miscellaneous additional charges associated 




with order. 




Type: Currency 


SKU 


Stock Keeping Unit, merchant's identifier 




for product 




Type: Cstring 


SbipMeihod 


Delivery services to be used in shipping product. 




Type: Cstring 


OrderURL 


URL string identifying Web site to send order 




for product 




Type: Cstring 


RefercnccURL 


URL string identifying Web site for information 




about the product 




Type: Cstring 


Pa y mc d tPric nd 1 y Name 


Reference to entry in Payment Database 




identifying source of payment if product 




is ordered (e.g., Visa, Checking Acct., etc.) 




Type: CString 


AddressFricndl yNamc 


Entry in Shipping Address DB identifying where 




to ship product 




Type: CString 


Flags 


0 if product has not been purchased; 1 if product 




has been purchased 




Type: DWORD 


There may be i 


i variety of properties associated with a 


product which are unique to that product and are not 


associated with other products. Such properties are repre- 


sented in name/value pairs in memory and can be referenced 


from an in-memory product structure through an associated 


pointer to a linked list of such properties. The property data 


are organized as shown in Table 3. 




TABLE 3 


Property Data Field Description 


Name 


Name of property 




Type: Cstring 


Miiuc 


Value of property 




Type: Variant 


Flags 


Stores various flag values 




Type: DWORD 


Merchant data preferably comprise associated fields as 


shown in Table 4. 






TABLE 4 


Merchant Data Field 


Description 


Logo 


Logo associated with merchant. 




Type: VOID* 


Logosize 


Size of logo associated with merchant. 




Type: DWORD 


Name 


Name of merchant. 




Type: Cstring 


Linel tern List 


Pointer to linked list of product data structures 



Type: Pointer 



The wallet object 408 is associated with wallet methods 
410 which provide access to payment source data (such as 
credit card numbers and checking account numbers) used for 
making on-line purchases. Payment source data are stored in 
memory preferably according to associated fields as shown 
in Table 5. 



18 



TABLE 5 


Payment Data Field 


Description 


Friendly Name 


Easily remembered and recognized name for 




payment source 




Type: Cstring 


CardNumber 


Credit card or account number 




Type: Cstring 


Expiration Date 


Date on which credit card expires. 




Type: Cstring 


CustomerName 


Name of card holder or account holder 




Type: Cstring 


Issuing Bank 


Name of bank issuing credit card or account 




Type: Cstring 


BUIToAddress- 


Reference to address database indicating address 


Fricndl yNamc 


to be billed when payment source is used to 




order product 




Type: Cstring 


The address book object 412 is associated with address 


book methods 414 which access address information for 


shipping purposes. The address book methods 414 access 


address data preferably organized as shown in Table 6. 




TABLE 6 


Address Data Field 


Description 


Friendly Name 


Easily remembered and recognized name 




for addresses 




Type: Cstring 


Name 


Name of person to receive parcels at address 




Type: Cstring 


Addressl 


First text line of shipping address. 




Type: Cstring 


Address2 


Second text line of shipping address 




Type: Cstring 


Address3 


Third text line of shipping address 




Type: Cstring 


City 


Name of city of shipping address 




Type: Cstring 


State 


Name of state of shipping address 




Type: Cstring 


Zip 


Zip code of shipping address 




Type: Cstring 


Country 


Name of country of shipping address 




Type: Cstring 


Phonel 


First phone number associated with 




shipping address 




Type: Cstring 


Phonc2 


Second phone number associated with 




shipping address 




Type: Cstring 



The shopping basket object 404, wallet object 408, and 

50 address book object 412 are preferably implemented as 
in-process COM (component object model) compliant 
objects, implemented as a single DLL (dynamic link 
library). The component object model is well-understood in 
the art and will not be further discussed. One skilled in the 

55 art will, however, appreciate that callable functions with 
appropriate associated data structures could be used in place 
of the shopping basket object 404, the wallet object 408, and 
the address book object 412 and their respective associated 
methods 406, 410, 414. 

60 FIG. 5 illustrates generally the type of data accessed by 
the primary objects of the commerce client. A shopping 
basket object 502 accesses and manipulates merchant data 
structures 504, product data structures 506, and product 
property data structures 508. A wallet object 510 accesses 

65 and manipulates payment source data structures 512. An 
address book object 514 accesses and manipulates address 
book data structures 516. 
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As described above, the commerce client 120 responds to 
various function-calling information embedded in MIME 
files of type "x-ishopper" passed from the Web Server 128 
through the Web browser 120, and also responds to function - 
calling information received indirectly from the Web 5 
browser 120 by way of a local port to which the Web 
browser directs data meant for the commerce client 122, The 
function-calling information identifies objects and methods 
which the commerce client 122 invokes. 

When viewing a Web document 310 which, for example, ]0 
describes a product (hosts an item) and which is coded 
according to the present invention, the standard Web 
browser displays an ADD ITEM -type option to the con- 
sumer which allows information about a product to be stored 
in the electronic shopping basket (in computer memory, and 15 
eventually written to a hard disk). The ADD ITEM option 
can be selected, for example, when the consumer has interest 
in the product, even if the consumer has not yet decided to 
purchase the product. The Web document 310 will also 
typically include a product form which is displayed on the 20 
consumer's computer screen. The product form represents a 
number of attributes which can be set by the consumer by 
filling in values. After setting attributes as desired (e.g., 
selecting a size or color for the product), the consumer 
selects the ADD ITEM option to store such "user prefer- 25 
ence" attributes along with the information provided by the 
merchant. 

FIG, 6 illustrates the steps performed when a consumer 
selects the ADD ITEM option. In a first step 602 the Web 
browser 120 issues an HTTP POST message to the Web 30 
server 128 indicating that a consumer has selected an ADD 
ITEM option. In a next step 604, the Web server 128 
retrieves product information from the merchant web site 
and sends the information to the Web browser 120 as a 
MIME message of type "x-ishopper." Next, in a step 606, 35 
the Web browser 120, after establishing receipt of a MIME 
message of type x-ishopper, launches the commerce client 
122 (if it is not already running). The commerce client, in a 
step 608, constructs an in-memory representation of 
merchant, product, payment, and address data read from a 40 
hard disk. Then, in a step 610, the Web browser 120 passes 
the MIME message to the commerce client 122. 

The commerce client 122 uses function-calling informa- 
tion embedded in the passed MIME message to call a 
method AddLineltem. In the step 612, the AddLineltem 45 
method navigates memory structures (constructed in step 
608) looking for a merchant data structure with a name field 
matching the merchant name passed with the MIME mes- 
sage. If no such merchant structure is found in the step 612, 
then a new merchant structure is appended to the linked list 50 
of merchants by allocating memory and the new merchant 
structure is populated with merchant data from the passed 
MIME message. The AddLineltem method then, in a next 
step 614, navigates a linked list of product data structures 
associated with the merchant structure (either found or 55 
created in the step 612). Each product data structure in the 
list represents one product offered for sale by a merchant. In 
the step 616, the AddLineltem method allocates memory for 
a new product data structure and populates it with data 
packaged in the MIME message such as product SKU, price, 60 
quantity, description, name, logo, color, or size. The AddLi- 
neltem method then links the new product data structure to 
the end of the linked product data structures for the mer- 
chant. 

In a step 618, the commerce client 122 invokes a Set- 65 
ItemProperty method wherein the linked list of merchant 
structures is again navigated until a merchant structure 
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having a merchant name matching the passed merchant 
name is found. In a step 620, the product data structures 
referenced by the merchant structure are navigated until a 
product data structure is found having an SKU field equiva- 
lent to the SKU number passed in the MIME message. Then, 
in the step 622, the SetltemProperty method navigates a 
linked list of properties referenced by the product data 
structure found, and does so for each property passed in the 
MIME message. When a property structure is found whose 
name matches the passed property name, the value associ- 
ated with the matched property name is replaced with a 
value passed in connection with the property name. In each 
case where the property list is navigated and no matching 
property name is found, the SetltemProperty method 
appends a new property data structure to the linked list of 
properties. The SetltemProperty method allocates memory 
for the new property data structure and fills in the name and 
value and flag fields as appropriate from the data in the 
passed MIME message. 

In a step 624, the commerce client 122 then executes the 
steps comprising the VIEW SHOPPING BASKET option 
described below. Thus, when the steps comprising the ADD 
ITEM option are completed, a new product data structure is 
stored in memory comprising data fields such as SKU, price, 
quantity, picture, description, reference URL, and merchant 
information. Also, any special properties associated with the 
product such as size, color, or finish, are also stored with the 
new product data structure. As explained below, default 
payment source information and default shipping address 
information are also associated with a new product data 
structure. 

Web documents 310 served by Merchant Web sites and/or 
stored locally on the consumer computer 102 offer consum- 
ers a selectable option called VIEW SHOPPING BASKET. 
This option allows consumers to retrieve a list of all the 
products that have been placed inside the electronic shop- 
ping basket using the ADD ITEM option. 

FIG. 7 illustrates the steps in carrying out the VIEW 
SHOPPING BASKET option. In a first step 702, the con- 
sumer selects the VIEW SHOPPING BASKET option from 
within the Web browser. In a next step 704, the Web browser 
120 issues a local function call. Then, in a step 706, the 
commerce client 122 is launched (if not already executing) 
by a local port monitor detecting the local function call. 
Next, in a step 708, the commerce client 122 loads the 
shopping basket COM object. In a next step 710, a variable 
CheckFlag is set equal to 0. Then, in a step 712, a loop is 
entered and is executed once for each merchant data struc- 
ture. 

In a step 714, the commerce client 122 invokes a Get- 
Firstltem method. In the step 714, the GetFirstltem method 
navigates to a given merchant. In this first iteration of the 
loop, the given merchant will simply be the first merchant in 
the merchant data structure list. In the step 716, the linked 
list of product data structures referenced from the first 
merchant data structure is navigated to the first product data 
structure. If, in the step 718, it is determined that there are 
no product data structures for this merchant or the naviga- 
tion of the product data structure list has reached the end of 
the list, then, in a step 720, the GetFirstltem method returns 
a value of 0. If in the step 718 it is determined that another 
product data structure exists and that the end of the product 
data structure list has not yet been reached, then the flag field 
of the product data structure is compared against the Check- 
Flag variable. Because CheckFlag is equal to 0, the product 
flag is being compared against the value 0 which would 
indicate that the product has not yet been purchased. If in the 
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step 722, it is determined that the product flag is not equal 
to the CheckFlag then processing reverts back to the step 
716 to check the next product data structure in the list. If, 
however, in the step 722, the product flag is equal to the 
CheckFlag, indicating that the product has not yet been 
purchased, then in a step 724, a pointer is returned pointing 
to the product data structure of the product that has not been 
purchased and the name of the product that has not been 
purchased is added to a list box structure. Next, in a step 726 
the pointer to the product data structure is saved and 
iterations of the loop are terminated. 

In the step 728, the GetNextltem method is invoked which 
begins by navigating to a given merchant. In the step 730, a 
current chain of linked product data structures is navigated 
to a point equal to a saved pointer location (the pointer 
location saved in step 726 if this invocation of GetNextltem 
immediately follows the termination of the GetFirstltem 
method, otherwise the pointer location saved in the step 742 
is used). Next, in the step 732, the next product data structure 
in the linked list is examined. If in the step 734 it is 
determined that the end of the product data structure list has 
been reached then in the step 736, a 0 is returned. If, 
however, in the step 734 it is determined that the end of the 
product data structure list has not yet been reached then, in 
the step 738, the product flag is compared against the 
CheckFlag. If in the step 738 the product flag is not equal to 
the CheckFlag then processing resumes in the step 732 
examining the next product data structure in the list. If 
however, in the step 738 the product flat is equal to the 
CheckFlag then, in the step 740, a pointer is returned to the 
product data structure and the name of the product is added 
to the list box structure. Next, in the step 742, a pointer to 
the product data structure is saved. The GetNextltem method 
is then invoked again beginning at step 728 where the ILst of 
merchant data structures is navigated to the current merchant 
and the steps 728 through 742 are repeated until the end of 
the merchant data structure is reached. 

When, in a step 744, the end of the merchant data 
structure list is reached, then in a step 746 a scrollable list 
of product names appears on the consumer's computer 
screen. The list of product names corresponds to all products 
currently in the electronic shopping basket which have not 
yet been purchased. 

Web documents 310 also offer consumers a VIEW HIS- 
TORY option. By selecting VIEW HISTORY, a list of 45 
product names is displayed on the user computer, all of 
which have been purchased. In one embodiment, the steps 
illustrated in FIG. 7 in relation to the VIEW SHOPPING 
BASKET option are all performed in relation to the VIEW 
HISTORY option with one exception. In performing the 
VIEW HISTORY option, the CheckFlag variable in the step 
710 is set equal to 1 instead of 0. Thus modified, the steps 
detect all product data structures whose flags are set to 1 
indicating that they have already been purchased. The steps 
of FIG. 7 then construct a list of product names reflecting all 
of the products that have been purchased. 

In another embodiment, selecting the VIEW HISTORY 
option causes a list of all product orders to be displayed. 
Each merchant structure has a reference pointer to a list of 
order structures. Each order structure, in addition to having 
fields for payment, shipping, and order tracking information, 
also has a reference pointer to a list of product structures. 
Thus, the linked list of merchants is traversed. For each 
merchant, the respective merchant's list of order structures 
is traversed. One display item is generated from each order 
structure. Each display item shows on the screen of the user 
computer, the purchase date, the payment information, the 
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shipping address, the order tracking identifier, and the prod- 
ucts ordered. Note, the products ordered are determined by 
traversing the linked list of product structures associated 
with each order structure. The VIEW HISTORY option 
advantageously allows consumers to examine past pur- 
chases whether such purchases occurred very recently or 
many years ago. 

The VIEW SHOPPING BASKET and VIEW HISTORY 
options do not require a connection to the Internet to operate. 
In addition, these functions can optionally be invoked with- 
out using the Web browser. To perform these functions 
without a Web browser 120, the consumer initiates execu- 
tion of the commerce client 122 by, for example, using a 
mouse and double-clicking an icon present on a graphical 
user interface of the consumer computer 102 (an icon with 
which the commerce client 122 executable program is 
associated). A commerce client user interface offers con- 
sumers a selection of options which do not require a con- 
nection to the Internet. These options are noted below to 
distinguish them from options which require Web-based 
communication. 

Web documents 310 of the system may also host a 
DELETE ITEM option to remove an item from the elec- 
tronic shopping basket. FIG. 8 illustrates the steps per- 
formed to carry out the DELETE ITEM option. In a first step 
802, the consumer selects the VIEW SHOPPING BASKET 
option and is presented with a list of products which have 
been gathered but which have not been purchased. The 
DELETE ITEM option is then presented. 

In a next step, 804, the consumer selects a product name 
from the list. Then, in a step 806, the consumer either selects 
the DELETE ITEM button or presses the delete key of the 
keyboard. The consumer is then prompted to confirm the 
deletion in a step 808. If the consumer does not confirm the 
deletion in the step 808, then, in a step 810, the steps of FIG. 
8 terminate. If, however, in the step 808, the consumer does 
confirm the deletion, then the DeleteLineltem method is 
invoked. 

A next step 812 then uses a pointer to the product data 
structure of the selected product to locate the preceding 
product data structure in a linked list. Locating a preceding 
structure in linked list is preferably done by implementing 
the list as a double linked list (one whose structures point 
both to the next structure as well as the preceding structure). 
It is possible that there is no preceding product data 
structure, that is, that the product data structure for the 
selected product is the first in the list of such product data 
structures that is referenced by a merchant data structure. In 
any case, a pointer to the product data structure will be 
located, it will simply belong to a merchant data structure 
rather than to a preceding product data structure. 

In a step 814, the same pointer to the product data 
structure of the selected product is used to locate a following 
product data structure (i.e., one which follows the product 
data structure corresponding to the selected product). It is 
possible that there is no following product data structure or, 
in other words, the product data structure of the selected 
product has a NULL pointer to the next product data 
structure. 

Finally, in a step 816, the pointer located in the step 812 
(i.e., the pointer which points to the product data structure of 
the selected product) is set to point to the product data 
structure which follows the product data structure of the 
selected product. In the case where there is no product data 
structure following the product data structure of the selected 
product, then the pointer located in the step 812 is simply set 
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to NULL. Thus, the product data structure of the selected GetAddressNextFriendlyName method 944 is used to navi- 

product is no longer referenced (is delinked) from the gate the linked list of shipping address structures, placing the 

in-memory data structures and is effectively deleted. The Friendly Name of each in the drop-down box already created 

DELETE ITEM option is offered to consumers via the in the step 918. 

commerce client user interface as well as on Web documents 5 Thus, a consumer can browse a list (displayed on the 

displayed by the Web browser 120. consumer's computer 102 screen as a scrollable list box) of 

Another option that is presented to a consumer following all properties and their corresponding values associated with 

selection of the VIEW SHOPPING BASKET option, is an the selected product and can modify the property values if 

option to SEE ITEM DETAILS. The SEE ITEM DETAILS desired. Also, the consumer can select from either of the two 

option allows a consumer to check the value of the unique *o drop-down boxes displayed on the consumer computer 102 

properties of a product (e.g., a selected color or size) as well to change the payment source to be used to purchase the 

as the payment source to be used in connection with a product or to change the shipping address for delivery of the 

purchase and also the address the product is to be shipped to product if purchased. 

if ordered. j n a s t e p 94^ a choice box is displayed to the consumer 

FIG. 9 illustrates the steps performed in relation to the 15 offering the choices OK or CANCEL. If, in the step 948, it 

SEE ITEM DETAILS option. First, in a step 902, the is determined that the consumer selected CANCEL, then, in 

consumer selects the VIEW SHOPPING BASKET button a step 950, the list box and the two drop-down boxes are 

and is presented with a list of products. In a next step, 904, cleared from the consumer computer and the steps of FIG. 

the consumer, selects a product name from the list. Then, in 9 terminate. If, however, in the step 948, the consumer 

a step 906, the consumer selecLs the SEE ITEM DETAILS 20 selected OK, then, in a step 952, a SetltemProperty method 

button. 954 is invoked to replace the values of the properties 

The Web browser 120 then, in a step 908, sends a local modified by the consumer, as well as to replace the Friendly 

HTTP POST message directed to a local port. A port listener Name for payment source or shipping address if either was 

responds to the message in a step 910, and forwards the changed by the consumer. The SEE ITEM DETAILS option 

message to the commerce client 122 in a step 912. 25 is present on the commerce client user interface as well as 

In a step 914, the commerce client 122 uses a pointer to °" Web documents, 

the product data structure of the selected product (this To manage payment source information, the present 

pointer is maintained following the selection of the product invention also allows a consumer to view and modify the 

in connection with the VIEW SHOPPING BASKET option) 3Q contents of an electronic wallet A Web document hosts 

to conveniently locate the product data structure of the (provides to a consumer) the option VIEW WALLET and 

product selected. Next, in a step 916, a drop-down box is includes embedded function-calling information which 

created having the Friendly Name of a payment source (i.e., invokes wallet-related functions. It will be understood that 

the value associated with the PaymentFriendlyName field of the Web browser 120 generates a HTTP POST message 

the product data structure) as the only entry. Similarly, in a 35 directed to the local consumer computer 102, and that a port 

step 918, a second drop-down box is created having the listener process receives the message and passes it to the 

Friendly Name of a shipping address (i.e., the value asso- commerce client 122 and also launches (executes) the com- 

ciated with the AddressFriendlyName field of the product merce client if necessary. 

data structure) as the only entry. FIG. 10 illustrates the steps performed in connection with 

A method GetFirstProperty 922 is then invoked and, in a 40 viewing and manipulating payment source data. In a first 

step 920, the GetFirstProperty method, examining the con- step 1002, the consumer selects the VIEW WALLET option, 

tents of a property list pointer associated with the product Next, in a step 1004, the commerce client 122, having 

data structure of the selected product, locates the first received the function-calling information from the port 

property data structure in a linked list of property data listener, loads the wallet object. In a step 1006, the GetPay- 

structures referenced by the product data structure, 4S mentFirstFriendlyName method 1008 is invoked to examine 

Next, a method GctNcxtPropcrty 924 is repeatedly called a maintained root pointer (a pointer to the first in a linked list 

in a step 926 to navigate the linked list of property data of payment source data structures) to determine the value of 

structures. In a step 928, a list box is created having an entry the Friendly Name associated with the first payment source 

for each property name/property value pair encountered in data structure. This first Friendly Name is used as the first 

navigating the linked list of property data structures. 50 entry in a list box. Next, in a step 1010, the GetPayment- 

In a step 930, a GetPaymentFirstFriendlyName method NextFriendlyName method 1012 is invoked to traverse the 

932 is invoked to examine the root pointer to the linked linked list of payment source data structures and place the 

payment source structures and to return the value of the Friendly Name associated with each as an entry in the list 

Friendly Name of the first payment source structure. A box. 

Friendly Name, as discussed below, is simply a name like 55 In the step 1014, a browsable list box is displayed to the 

"Bob's Visa Card" which is conveniently used to designate consumer, listing all Friendly Names assigned to payment 

a payment source. In the step 934, the GetPaymentNext- sources. In a next step 1016, options to ADD, EDIT, 

FriendlyName method 936 is used to navigate the linked list DELETE payment sources are presented to the consumer, as 

of payment source structures, placing the Friendly Name of is an option to MAKE PREFERRED (establish as the 

each in the drop-down box already created in the step 916. 60 default) one of the payment sources. 

In a next step 938, a GetAddressFirstFriendlyName If, in the step 1016, the consumer selects the ADD 

method 940 is invoked to examine the root pointer to the payment source option, then, in a step 1018, a dialog box is 

linked shipping address structures and to return the value of displayed with blank or incomplete fields corresponding to 

the Friendly Name of the first shipping address structure. A payment source information. The fields are designed to elicit 

Friendly Name, as used with respect to an address, is a name 65 information such as credit card number, issuing bank, expi- 

like "the office" or "Debbie's house" which is conveniently ration date, name on card, Friendly Name, and billing 

used to designate a shipping address. In the step 942, the address. The consumer can enter information corresponding 
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to a credit card, debit card, or any other cash substitute. 
Then, in a step 1020, the consumer fills in the fields and, if 
the consumer desires to retain the entered information in the 
electronic walk l, the user is prompted to enter a password 
twice for verification in a step 1022. When the passwords are 
typed correctly twice, then in a step 1024, the password is 
used to encrypt the entered payment source data, and the 
encrypted data is stored in association with the Friendly 
Name entered by the consumer which is not encrypted. The 
consumer can then exit from viewing the wallet or continue 
with further manipulations of payment source data. 

If, in the step 1016, the consumer selects EDIT payment 
source data, then upon selecting a Friendly Name corre- 
sponding to payment source data, the consumer, in a step 
1026 is prompted to enter a password. If the password is 
correct, it is used to decrypt the encrypted payment source 
information associated with the selected Friendly Name. In 
a step 1028, the decrypted payment source information is 
presented to the consumer in a dialog box. The data are 
broken into fields for consumer editing. 

In the step 1030, the consumer modifies the data fields. 
When the consumer is finished updating payment source 
information, the consumer, in a step 1032, is prompted to 
enter a password twice. This password may be different from 
the password entered earlier to access the payment source 
data. When the password is successfully entered, the 
updated payment source data is encrypted and stored in 
association with the Friendly Name (which is not encrypted) 
1034. Password protection at the consumer computer 102 
level is an advantage of the present invention which ensures 
that only one person has access to credit card numbers and 
other financial information. 

In the step 1016, the consumer may elect to DELETE 
payment source data. Upon selecting from the list box of 
step 1014 a Friendly Name corresponding to payment source 
data to be deleted and also selecting the DELETE payment 
source option, the consumer is asked, in a step 1036, to 
confirm the deletion request. If the consumer confirms the 
deletion, then payment source data associated with the 
selected Friendly Name is removed from the linked list of 
payment source data structures 1038. It will be appreciated 
by those skilled in the art that a password prompt can be 
added to the deletion steps to protect against undesired 
deletions. 

The step 1016 also offers the option to MAKE PRE- 
FERRED one of the payment sources. Making a payment 
source preferred causes its Friendly Name to be associated 
by default with product information that is added to the 
electronic shopping basket. Generally, a preferred payment 
source would be an often used credit card account perhaps 
offering a very competitive interest rate or earning for the 
cardholder airline frequent flyer miles whenever money is 
spent. If the consumer, in the step 1016, selects a Friendly 
Name from the list box of step 1014, and then selects MAKE 
PREFERRED, the Friendly Name selected becomes, in the 
step 1040, associated with the default payment source. One 
of ordinary skill will understand that a confirmation check 
could be added to the MAKE PREFERRED steps to avoid 
unintended replacements of a prior default payment source. 
When the consumer is finished viewing and manipulating 
payment source data, the user terminates the VIEW WAL- 
LET options and screen display by selecting an EXIT (or 
similarly labeled) button. 

Very similar to the manner in which the present invention 
facilitates viewing and manipulating payment source data in 
the electronic wallet is the manner in which it permits 
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consumers to view and manipulate shipping address data in 
the electronic address book. FIG. 11 illustrates the steps in 
viewing or manipulating address book data. In a first step 
1102, the consumer selects a VIEW ADDRESS BOOK 

5 option. In a next step 1104, the commerce client 122 loads 
the address book object. 

In a step 1106, the GetAddressFirstFriendlyName method 
1108 uses a maintained root pointer (always points to the 
first of a linked list of shipping address data structures) to 

10 examine the first shipping address data structure and to 
return the associated Friendly Name. A Friendly Name for a 
shipping address might be, for example, "My Castle," or 
"Jill's Office." The Friendly Name associated with the first 
shipping address data structure is used as the first entry in a 

15 browsable list box. 

Next, in a step U10, the GetAddressNextFriendlyName 
method 1112, is used to traverse the linked list of shipping 
address data structures and to include the Friendly Name 
associated with each structure in the list box created in step 

20 1106. The list box is displayed to the consumer in step 1114. 
A step 1116 presents options to the consumer to ADD, EDIT, 
DELETE snipping address data, as well as to MAKE 
PREFERRED a shipping address. 

25 If, in the step 1116, the consumer elects to ADD shipping 
address data, then, in a step 1118, a dialog box is displayed 
to the consumer containing blank or incomplete fields cor- 
responding to shipping address data such as street address, 
city, state, country, zip code, name, and Friendly Name. In 

3Q a next step 1120, the consumer enters information into the 
fields. When the consumer is satisfied that the information is 
complete and accurate, the consumer selects the OK button 
in the step 1122, and the new shipping address is saved in 
association with the new Friendly Name entered. 

35 As with the electronic wallet, the consumer can also elect 
to EDIT data in the electronic address book. Because there 
is not as much need for security, there is no password access 
to or encrypting performed on the shipping address data. 
One skilled in the art will understand that password- 

40 protected access could be implemented in connection with 
the shipping address data as specified with respect to the 
payment source data. If the consumer elects to EDIT ship- 
ping address data, then, after selecting a Friendly Name 
from the browsable list displayed in the step 1114, a dialog 

45 box is displayed in a step 1124 presenting fielded data items 
corresponding to the existing data associated with the 
selected Friendly Name. In the step 1126, the consumer 
modifies the existing shipping address data. When satisfied 
that the changes are complete, the consumer selects an OK 

50 button in a step 1128 which saves the changed shipping 
address information in association with the Friendly Name 
(which may have just been changed by the user). 

If, in the step 1116, the consumer elects to DELETE 
shipping address data, then, after selecting a Friendly Name 

55 corresponding to a shipping address, the user is prompted in 
a step 1130 to confirm the delete request. If the consumer 
confirms the delete request in the step 1130, then in a step 
1132 the shipping address data is deleted along with the 
Friendly Name. 

60 If the option to MAKE PREFERRED a shipping address 
is selected in the step 1116, then, in a step 1134 the shipping 
address data associated with the selected Friendly Name is 
associated with the default shipping address. Thereafter, any 
products placed into the electronic shopping basket will 

65 acquire automatically, by default, an association with the 
new shipping address. One skilled in the art will appreciate 
that a confirmation step such as that in step 1130 with respect 
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to deleting shipping address data could be added to safe- prompted for a password to authorize payment from the 

guard against unintended modifications to the default ship- payment source associated with the passed PaymentFriend- 

ping address. Note that both the VIEW WALLET and VIEW lyName. If the password is incorrect, the purchase is not 

ADDRESS BOOK options are available from the commerce authorized and the next subgroup of products is identified 

client user interface. 5 whereupon step 1222 repeats. If, however, the password is 

„-.. 4 . c . . . „ . correct, then the encrypted payment source data is decrypted 

With payment source information m the electronic wallet jn a ^ ^ a ^ P n / instruclion is formed from H lhe 

and shipping address information in the electronic address £ ^ m info ^ atkm and lhe ducl iaformatioa . 

book, the present invention enables a consumer to purchase ^ e instruction contains data sufficient to allow a 

products in the electronic shopping basket. Web documents merc hant to complete the order. In a next step, 1250, the 

host a READY TO BUY option. 3 p ayment instruction along with the product list is passed to 

FIG. 12 illustrates the steps of purchasing a product. In a an encryption DLL to be encrypted. The encryption DLL 

first step 1202, the consumer selects the READY TO BUY uses RSA encryption technology (a form of public/private 

option. Next, in a step 1204, the shopping basket object is key encryption) which is known. The present invention is 

loaded. Then, in a step 1206, the GetFirstltem method 1208 riot limited by encryption technology, and other forms of 

is used to examine a maintained root pointer to the first 15 encryption could be used. The GenerateGSOPI method 1242 

merchant data structure and to then traverse and examine the then passes the encrypted order to a step 1232 wherein the 

linked list of product data structures associated with the first order is ^ to a merchant's order URL (held as a field 

merchant and return the first located unpurchased product. associated with a product data structure) as part of an HTTP 

The Flag of each product data structure is examined to P° ST message. Thus, the commerce c^nt 122 is able to 

determine if the product is already purchased. If no unpur- 20 gp« the Web browser and transmit HTTP POST messages 

chased products are discovered in association with the first 1 t ' . . , 

merchant data structure, the GetFirstltem moves to the next „f ler an order, the commerce client 122 then 

. . . t * i 1*1 j 1** c i_ * tit updates the in memory structure for the respective merchant, 

merchant structure in the linked list or merchants. The „ r , i_ . . £ • i j r **. 

., . r v Each merchant structure includes a reference pointer to a 

GetFirstltem method returns information (such as -a pointer) ljnked Hst of Qrder slructures> ^ clienl 122 

identifying the first product structure associated with an ^ ^ M q£ ^ structureSj tf t0 reach 

unpurchased product encountered in iLs traversal of the the final order structure. The commerce client 122 allocates 

merchant and product structures. memory for a new order structure, links the new structure to 

In a next step 1210, the GetNextltem method 1212 is used the list of order structures for the merchant, and then 
to complete the traversal of the merchant and product 3Q populates the new order structure with payment information, 
structures, returning information identifying all product shipping address information, and a pointer to the product 
structures associated with unpurchased products. In a step structure associated with the product ordered. An order 
1214, a list of all unpurchased products is generated and is tracking identifier ("Oil") field of the new order structure is 
then sorted by merchant and by PaymentFriendlyName. left blank. One skilled in the art will appreciate that linked 
Next, in a step 1216, the list of unpurchased products is 35 lists ofstructures is merely oneway of associating data items 
displayed to the consumer, and the consumer is prompted to together, and that other methods such as relational databases 
confirm the purchase request. If, in the step 1216, the can be used to accomplish a similar association, 
consumer confirms the purchase, then the wallet object is A mer chant site receiving a product purchase order trans- 
loaded in a step 1218. Otherwise, the steps of FIG. 12 are m i ts an order confirmation message to a Web browser 120. 
terminated and no purchase occurs. 4Q order confirmation message transmits an order tracking 

With the unpurchased product items in the electronic identifier ("OTI") to the Web browser 120. The Web browser 

shopping basket sorted by merchant (e.g. "L.L. Bean" or 120 displays the OTI on the screen of the user computer, 

"Sears"), a step 1220 divides the product items into groups, along with a message which states, for example, "Thank you 

one group per merchant. A first product group associated for your order. If there is any problem, please phone 1 800 

with a first merchant is designated for processing. A step 45 123 4567 and be prepared to refer to the following order 

1222 then divides (or sorts) the first group into further tracking identifier." The OTI is also embedded in a MIME 

subgroups according to the value of the PaymentFriend- message of type x-ishopper which is passed by the Web 

lyName (e.g., "Gold Card" or "Mary's Amex"). Thus, browser 120 to the commerce client 122. The commerce 

different orders can be submitted to one merchant, but paid client 122 then copies the OTI to the blank OTI field of the 

for using different payment sources. 50 order structure, thus completing the storage of information 

One having ordinary skill in the art will appreciate that a related to the purchase, 
third subgrouping could be performed such as, for example, A step 1234 determines whether additional products for 
a subgrouping based on the value of AddressFriend lyName the current merchant remain to be purchased. If so, process- 
(e.g., "Grandma's House" or "Alaska Cabin"). Such an ing resumes at the step 1222, and, if not, processing resumes 
additional subgrouping would conveniently support orders 55 upon the next group of products from the next merchant at 
which could be submitted to one merchant, cause payment the step 1220. A step 1236 determines whether all products 
from different payment sources and assist the merchant in for all merchants have been purchased. If not, then process- 
shipping products to different locations. Further, products ing resumes with the step 1220. If all products have been 
paid for from the same payment source could conveniently purchased as determined by the step 1236, then the Flag field 
be shipped to different addresses. go for every product in the electronic shopping basket is 

Associating a group of products for a single merchant that marked "purchased" (i.e., set equal to 1). Finally, in a step 

are to be purchased from a single payment source, a GSO 1240, the steps comprising the VIEW SHOPPING BASKET 

(goods and services order) is submitted to the GenerateG- option and the VIEW HISTORY option are invoked to force 

SOPI method 1242 on the wallet object. In a step 1224, the updates to memory structures and screen displays to avoid 

GenerateGSOPI method 1242 extracts the stored and 65 confusion as to whether any product was in fact purchased, 

encrypted data (or blob) associated with the passed Pay- An ORDER STATUS option is presented to a user by the 

mentFriendlyName. In a next step, 1226, the consumer is commerce client 122 after selection of the VIEW HISTORY 
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option. Once a list of orders is generated and displayed to the 
user as described above, the user selects an order (preferably 
by positioning a mouse pointer over information associated 
with an order and clicking a mouse button). The user then 
selects the ORDE R STA TUS option. The commerce client 
then generates an HTTP POST message containing the order 
tracking identifier ("OTI"), and transmits the HTTP POST 
message to the order URL (uniquely identifying the Internet 
address of the selling merchant) associated with the product 
(or products) purchased. A merchant site receiving an HTTP 
POST message which includes an OTI determines the status 
of the order (e.g., "SHIPPED," "CANCELED," "WAITING 
FOR INVENTORY," etc.). The merchant site transmits an 
HTML document to the Web browser which includes the 
status information. The Web browser of the user computer 
displays the status information on the screen of the user 
computer. 

A consumer receives on-line assistance (or help) in using 
a computer-based shopping system by selecting a HELP 
option. In one embodiment, the HELP option is included in 
the HTML coding of a Web document and displayed to the 
user by a Web browser. Selecting the HELP option causes 
the Web browser 120 to access a HELP Web site. 

In another embodiment, the HELP option is displayed to 
the user by the user interface of the commerce client 122. 
Selecting the HELP option in this embodiment causes the 
commerce client 122 to establish a TCP/IP communication 
link to another computer if such a link is not already 
established. The commerce client 122 transmits an HTTP 
POST message directly to a HELP Web site. The commerce 
client 122 causes the Web browser 120 to begin running on 
the user computer if it is not already running. 

In either embodiment of the HELP option, the Web 
browser displays help information included in documents 
served by a Web server of the HELP Web site. The help 
information, for example, describes the use of the computer- 
based shopping system or the cause of errors encountered in 
operating the computer-based shopping system, offers tips, 
or illustrates features of the computer-based shopping sys- 
tem wiLh pictures and diagrams. One skilled in the art will 
appreciate that on-line help could alternatively be made 
available to consumers via a hierarchically ordered (topics, 
subtopics, and sub-subtopics) collection of information 
residing on the consumer computer 102. 

A consumer conveniently accesses a merchant Web site 
302 from which product information has been obtained by 
selecting the JUMP TO MERCHANT option. The user 
interface of the commerce client includes the JUMP TO 
MERCHANT option. By maintaining an association 
between a product name and a merchant Web site URL 
within the product data structure of every product, a 
computer-based shopping system locates a URL associated 
with the merchant selling a product by accessing the product 
data structure for the product. The commerce client 122 
generates an HTTP POST message accessing the merchant 
Web site associated with the product. The merchant Web site 
responds by transmitting an HTML document to the Web 
browser 120. Thus, the consumer conveniently accesses the 
Web site from which information about a product was 
obtained. 

A consumer terminates a computer-based shopping sys- 
tem by selecting an EXIT button. The EXIT button causes 
the commerce client 122 to write linked in-memory data 
structures to a hard disk (other storage devices can suffice) 
in a manner which preserves the link relationships. The 
commerce client 122 then stops executing on the consumer 
computer 102. 
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This invention may be embodied in other specific forms 
without departing from the essential characteristics as 
described herein. The embodiments described above are to 
be considered in all respects as illustrative only and not 
restrictive in any manner. The scope of the invention is 
indicated by the following claims rather than by the fore- 
going description. Any and all changes which come within 
the meaning and range of equivalency of the claims are to be 
considered within their scope. 

In the claims which follow, alphabetic characters used to 
designate claim steps are provided for convenience of 
description only, and are not intended to imply any particular 
order for performing the steps. 

What is claimed is: 

1. A client architecture for conducting electronic com- 
merce over the Internet, comprising, on a computer-readable 
medium: 

a Web browser configured to run on a computer; 

a commerce client application configured to run on the 
computer in conjunction with the Web browser appli- 
cation to provide a user interface, the commerce client 
application including a callable function, said callable 
function comprising executable computer instructions 
stored on a computer storage medium accessible by the 
computer; 

an electronic shopping basket object configured to access 
and manipulate product information and merchant 
information stored on the computer storage medium, 
the access and manipulation initiated by executing the 
callable function of the commerce client application; 

at least two Web documents, each of which includes 
embedded function-calling information that corre- 
sponds to the callable function of the commerce client 
application, the function-calling information embedded 
within the Web document such that a user can selec- 
tively initiate the execution of the callable function via 
the user interface while viewing one of the Web docu- 
ments with the Web browser; and 

wherein the user interface is displayed for each of the Web 
documents and functions independently of the Web 
documents. 

2. The client architecture according to claim 1, wherein 
the commerce client application includes a second callable 
function, and wherein each Web document includes embed- 
ded function-calling information that corresponds to the 
second callable function of the commerce client application, 
the execution of the second callable function selectively 
initiated by the user while viewing one of the Web docu- 
ments with the Web browser, the client architecture further 
comprising, on the computer-readable medium: 

an electronic wallet function configured to access and 
manipulate payment source information stored on the 
computer storage medium, the access and manipulation 
of the payment source information initiated by execut- 
ing the second callable function of the commerce client 
application. 

3. The client architecture according to claim 1, wherein 
the commerce client application includes a second callable 
function, and wherein each Web document includes embed- 
ded function-calling information that corresponds to the 
second callable function of the commerce client application, 
the execution of the second callable function selectively 
initiated by the user while viewing one of the Web docu- 
ments with the Web browser, the client architecture further 
comprising, on the computer-readable medium: 

an electronic address book function configured to access 
and manipulate shipping address information stored on 
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the computer storage medium, the access and manipu- 
lation of the shipping address information initiated by 
executing the second callable function of the commerce 
client application. 

4. A client architecture for conducting electronic com- 5 
merce over the Internet, comprising, on a computer-readable 
medium: 

a Web browser configured to run on a computer; 

a commerce client application configured to run on the 
computer in conjunction with the Web browser 30 
application, the commerce client application including 
a callable function and a user interface; 

an electronic shopping basket function configured to store 
product information and merchant information to a 
computer storage medium accessible by the computer, 15 
said electronic shopping basket function comprising 
executable computer instructions stored on a computer 
storage medium accessible by the computer, the prod- 
uct information and merchant information retrieved 
from merchant Web sites over the Internet via the Web 20 
browser, the storing initiated by executing the callable 
function of the commerce client application; 

at least two Web documents, each of which includes 
embedded function-calling information that corre- 
sponds to the callable function of the commerce client 25 
application, the function-calling information embedded 
within the Web document such that a user can selec- 
tively initiate the execution of the callable function via 
the user interface while viewing one of the Web docu- 
ments with the Web browser; and 30 

wherein the user interface is displayed for each of the Web 
documents and functions independently of the Web 
documents. 

5. A client architecture for conducting electronic com- 
merce over the Internet, comprising, on a computer-readable 35 
medium: 

a Web browser configured to run on a computer; 

a commerce client application configured to run on the 
computer in conjunction with the Web browser 4Q 
application, the commerce client application including 
a callable function and a user interface; 

an electronic shopping basket function configured to store 
product information and merchant information to a 
computer storage medium accessible by the computer, 45 
said electronic shopping basket function comprising 
executable computer instructions stored on a computer 
storage medium accessible by the computer, the prod- 
uct information and merchant information obtained 
from merchant Web sites over the Internet via the Web 50 
browser, the retrieval initiated by executing the callable 
function of the commerce client application; 

at least two Web documents, each of which includes 
embedded function-calling information that corre- 
sponds to the callable function of the commerce client 55 
application, the function-calling information embedded 
within the Web document such that a user can selec- 
tively initiate the execution of the callable function via 
the user interface while viewing one of the Web docu- 
ments with the Web browser; and 60 

wherein the user interface is displayed for each of the Web 
documents and functions independently of the Web 
documents. 

6. A client architecture for purchasing products over the 
Internet, comprising, on a computer-readable medium: es 

a commerce client application configured to run on a 
computer and having a user interface, the commerce 
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client application configured to transmit information to 
a World Wide Web site in accordance with World Wide 
Web protocols, the commerce client application con- 
figured to run in conjunction with a Web browser, the 
commerce client application including a product pur- 
chase function which combines product information, 
merchant information, and payment source information 
and transmits the combined information to a World 
Wide Web site, the product purchase function compris- 
ing executable computer instructions stored on the 
computer-readable medium; 
a Web browser configured to run on the computer; and 
at least two Web documents, each of which includes 
embedded function-calling information that corre- 
sponds to the product purchase function of the com- 
merce client application, the function-calling informa- 
tion embedded within the Web document such that a 
user can selectively initiate the execution of the product 
purchase function via the user interface while viewing 
one of the Web documents with the Web browser; and 
wherein the user interface is displayed for each of the Web 
documents and functions independently of the Web 
documents. 

7. The client architecture according to claim 6, further 
comprising, on the computer-readable medium; 

an electronic shopping basket object configured to access 
and manipulate product information and merchant 
information stored on a computer storage medium, the 
electronic shopping basket function transmitting prod- 
uct information and merchant information to the com- 
merce client application during execution of the prod- 
uct purchase function of the commerce client 
application, the electronic shopping basket object com- 
prising executable computer instructions stored on the 
compute-readable medium. 

8. The client architecture according to claim 6, further 
comprising, on the computer- readable medium; 

an electronic wallet object configured to access and 
manipulate payment source information and merchant 
information stored on a computer storage medium, the 
electronic wallet object transmitting payment source 
information and merchant information to the commerce 
client application during execution of the product pur- 
chase function of the commerce client application, the 
electronic wallet object comprising executable com- 
puter instructions stored on the compute-readable 
medium. 

9. A method for gathering product information over a 
distributed network, comprising: 

(a) receiving a first hypertext document over the distrib- 
uted network at a user computer, the first hypertext 
document comprising (I) a description of a first 
product, (ii) a user-selectable product gathering option, 
and (iii) function-calling information associated with 
the product gathering option; 

(b) displaying the first hypertext document to a user via a 
user interface on the user computer and monitoring user 
input for selection of the product gathering option; 

(c) responding to user selection of the product gathering 
option by passing at least a portion of the function- 
calling information from a Web browser to a local 
process running on the user computer, the local process 
calling an executable function specified by the 
function-calling information, the function storing the 
description of the first product to a local data storage 
area of the user computer; 
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(d) receiving a second hypertext document from a second 
site over the distributed network at the user computer, 
the second hypertext document comprising (i) a 
description of a second product, (ii) a second selectable 
product gathering option, and (iii) function-calling 
information associated with the second product gath- 
ering option; 

(e) displaying the second hypertext document to the user 
via the user interface of the user computer and moni- 
toring user input for selection of the second product 
gathering option; and 

(f) responding to user selection of the second product 
gathering option by calling a second executable 
function, the second function storing the description of 
the second product to the local data storage area. 

10. The method according to claim 9 wherein step (a) 
comprises sending an HTML document over the distributed 
network from a Web server running on a merchant Web site 
to a Web browser running on the user computer, the Web 
server in a location remote to the Web browser. 

11. The method according to claim 9, further comprising 
the steps of: 

(g) displaying a product comparison option to the user via 
the user computer and monitoring user input for selec- 
tion of the product comparison option; and 

(h) responding to user selection of the product comparison 
option by retrieving from the local storage the descrip- 
tion of the first product and the description of the 
second product, and by formatting the descriptions and 
displaying the descriptions to the user via the user 
computer. 

12. A method for using a Web browser to manage local 
data, the Web browser running on a user computer, the local 
data stored on a computer storage medium accessible by the 
user computer, the method comprising the steps of: 

(a) receiving with the Web browser a first HTML docu- 
ment and a second HTML document, each HTML 
document comprising a user-selectable view option and 
function-calling information associated with the view 
option; 

(b) displaying the first HTML document and the user- 
selectable view option to a user via a user interface on 
the user computer; 

(c) monitoring user input for selection of the view option; 

(d) responding to selection of the view option by calling 
a view function specified in the function -calling 
information, the view function comprising executable 
computer instructions accessible by the computer, the 
view function accessing and formatting the local data 
and displaying the local data to the user; 

(e) displaying the second HTML document and the user- 
selectable view option to the user via the user interface; 

(f) monitoring user input for selection of the view option; 
and 

(g) responding to selection of the view option by calling 
a view function specified in the function -calling 
information, the view function comprising executable 
computer instructions accessible by the computer, the 
view function accessing and formatting the local data 
and displaying the local data to the user. 

13. A method according to claim 12 wherein the calling of 
the view function of step (d) is performed by sending a 
message which includes at least a portion of the function- 
calling information from the Web browser to a local Internet 
address representing the user computer, a local port- 



monitoring process monitoring the local Internet address and 
receiving the message, the local process using the function- 
calling information to make the function call. 

14. A method according to claim 12 wherein the calling of 

5 the view function of step (d) is performed by sending a 
message which includes at least a portion of the function- 
calling information from the Web browser to a local Internet 
address representing the user computer, a first local process 
monitoring the local Internet address and receiving the 

10 message, the first local process invoking a second local 
process if it is not already running, the first local process 
passing at least the function-calling information to the 
second local process, the second local process using the 
function-calling information to call the view function. 

15 15. A method according to claim 12 wherein the view 
function further comprises displaying an add option to the 
user via the user interface, the method further comprising the 
steps of: 

(e) monitoring user input for selection of the add option; 
20 (f) responding to selection of the add option by prompting 
the user to enter additional local data; 
(g) monitoring user input for entry of additional local 
data; and 

25 (h) responding to entry of additional local data by storing 
the additional local data on the computer storage 
medium. 

16. A method according to claim 12 wherein the view 
function further comprises displaying an edit option to the 
3 q user via the user interface, the method further comprising the 
steps of: 

(e) monitoring user input for selection of the edit option; 

(f) responding to selection of the edit option by prompting 
the user to select displayed local data; 

(g) monitoring user input for selection of displayed local 
data; and 

(h) responding to selection of displayed local data by 
presenting the selected local data to the user for editing 

4Q via the user computer and by displaying a done option; 

(i) applying edit operations performed by the user via the 
user computer to the selected local data to generate 
edited local data; 

(j) monitoring user input for selection of the done option; 
45 and 

(k) responding to selection of the done option by remov- 
ing the selected local data from the computer storage 
medium and by storing the edited local data on the 
computer storage medium. 
50 17. A method according to claim 12 wherein the view 
function further comprises displaying a delete option to the 
user via the user interface, the method further comprising the 
steps of: 

(e) monitoring user input for selection of the delete 
option; 

(f) responding to selection of the delete option by prompt- 
ing the user to select displayed local data; 

(g) monitoring user input for selection of displayed local 
60 data; and 

(h) responding to entry of displayed local data by remov- 
ing the selected local data from the computer storage 
medium. 

18. A method according to claim 12 wherein the local data 
65 represent at least one source of credit or source of funds. 

19. A method according to claim 12 wherein the local data 
represent at least one postal address. 



35 



55 



11/22/2003, EAST version: 1.4.1 



6,125, 

35 

20. A method, comprising the following steps: 
accessing a first merchant site from a user computer via a 

user interface on the user computer; 
gathering first product information from the first merchant 

site; 5 
storing the first product information locally on the user 

computer; 

accessing a second merchant site from the user computer 
via the user interface; 3 q 

gathering second product information from the second 
merchant site; 

storing the second product information locally on the user 
computer; and 

concurrently analyzing the first product information and 15 
the second product information at the user computer. 

21. A method as recited in claim 20, wherein the concur- 
rently analyzing step comprises the step of analyzing the 
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first product information and the second product information 
offline at the user computer. 

22. A method as recited in claim 20, further comprising 
the step of displaying the first product information and the 
second product information concurrently to a user. 

23. A method as recited in claim 20, further comprising 
the step of storing first and second ordering information for 
ordering products from the first merchant site and from the 
second merchant site. 

24. A method as recited in claim 23, further comprising 
the step of selectively transmitting the first ordering infor- 
mation to the first merchant site and selectively transmitting 
the second ordering information to the second merchant site. 

25. A method as recited in claim 24, further comprising 
the step of selectively tracking status of the first ordering 
information and selectively tracking status of the second 
ordering information. 

***** 
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